REMARKS 

Claims 1, 9, 13-16, 20-24, and 26 are pending in the present application. Claims 13, 
16, 20, 21, 23, 24 and 26 have been amended. The paragraph numbering in the Office Action 
has been adopted in these Remarks. 

Rejections under 35 U.S.C. $ 102 

Claims 20-23 

1. Claims 20-23 have been rejected under 35 U.S.C. § 102(e) as being anticipated by a 
typical Web browser banner ad, as exemplified in U.S. Patent No. 6,016,504 to Arnold et al. 
("Arnold"). 

The Office Action states that a typical web banner ad is a program object with limited 
functionality that is downloaded for use in a browser host application. If a user clicks on the 
banner ad, a request is sent to the server computer requesting the fiill home page 
corresponding to the banner ad. In this latter transmission, the entire full home page is 
downloaded by the user's client computer. 

In contrast, the present invention is a system for requesting and receiving only the 
missing functional components - that is, only those functional components of the full 
functionality object that do not already exist in the limited functionaUty object. To yield a 
full functionality object in the present invention, the client computer integrates the functional 
components requested and received from the server computer in steps (c) and (d) of claim 20 
with the limited functionality object referenced in steps (a) and (b). The entire full 
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functionality object need not be downloaded by the user's client computer. 

Again, this is in direct contrast with the typical Web browser ad example, and Arnold, 
where the downloaded full home page is not integrated with the already existing banner ad, 
but rather replaces the banner ad. At most, the downloaded full home page can be said to 
integrate with the browser host application. This does not disclose step (e) of the amended 
claim 20. 

Moreover, the present invention's specification defines an object, of which a limited 
functionality object and full functionality object are types, as including: 

a combination of computer data and/or logic that encapsulates 
or simulates the realization and/or functionality of a real or 
imaginary object. 

See page 32, line 7 of the present invention's specification. For example, the program 
code and data corresponding to a virtual car can be an "object" for the purposes of the present 
invention, because it simulates a real-life car. Equally, the program code and data 
corresponding to the steering wheel of that virtual car can be an "object", because it simulates 
a real-Ufe steering wheel. A web page and a web banner ad, on the other hand, do not purport 
to simulate anything. They may include program code (such as JavaScript), and data, but they 
do not teach or suggest the invention of claim 20. 

These same distinctions apply equally to the simple html hyperlink example cited in 
the Office Action at page 4. 
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Further in regard to claim 21, the Office Action states at page 4 that the typical web 
banner ad, as exemplified by Arnold, teaches that the full functional object is unique, in that 
there is only one homepage linked to the banner ad. With respect, this statement ignores the 
fact that the same homepage may be downloaded by, and simultaneously exist on, many 
different client computers. Although there may be only one homepage on the server 
computer, there are multiple identical homepages stored (albeit temporarily) on every client 
computer that accesses the homepage. According to claim 21, unlike the homepage example 
cited by the Office Action, the full functionality program object may only be created once. It 
may not be created again, for instance, for use by a different user on a different client 
computer. 

By way of a non-limiting example, and as explained on page 17, line 29 of the 
specification of the present invention, a full functionality car may have the unique number 
plate of "ABC- 123". As is the case for unique and unusual number plates in reality, it is 
uniqueness that may give these virtual objects their value. In the embodiment of claim 21, no 
other user may have a full functionality instance of this car. Other users on other client 
computers may be able to view this car as it is driven down the virtual highway by its owner 
in a multi-player game. The host applications of these other users may have a limited 
functionality instance of this car (so that their users may see the car and be "taunted" by it), 
but they cannot have a full functionality instance of it (and therefore cannot, for example, 
manipulate the car). This is the "uniqueness" referred to in claim 21. 

In regard to claim 22, the Office Action states that in the typical banner ad situation, 
as exemplified by Arnold, the user may provide identifying and payment data to the server 
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computer. As explained above in respect of claim 20, on which claim 22 depends, Arnold 
teaches the downloading of the entire web page that corresponds to the banner ad. Arnold 
does not teach the downloading of only the missing parts of a homepage. Arnold does not, 
therefore, disclose all the elements of claim 22. 

hi regard to claim 23, the Office Action states at page 4 that the full home page may 
be transmitted to a second client computer. This is correct as far as it goes, but the 
transmission the Examiner refers to is the transmission of the home page to the second client 
computer from the web server. This is different to claim 23, where the full functionality 
object is transmitted to a second client computer from the first client computer. Nowhere 
does Arnold teach or suggest that a homepage may be transmitted between client computers, 
nor is this common in the art. Certainly, the Examiner has not adduced any evidence of this. 

Rejection under 35 U.S.C. S 103 

Claim 1 

2. Claim 1 is rejected as being unpatentable over U.S. Patent No. 6,668,375 to Leovac 
("Leovac"), in view of U.S. Patent No. 6,282,71 1 to Halpem et al. ("Halpem"). 

Leovac teaches a method in which a user is provided software on an installation 
medium, such as a CD. The user may initially be allowed to use only a subset of software 
options that are available on the installation medium. Upon request by the user, additional 
options existing on the installation medium may be unlocked with a key sent to the user. 
Note that in Leovac, the key and not the additional program parts are sent to the user. See 
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col. 3, lines 37-38 of Leovac, and page 6 of the Office Action. Thus, the system taught by 
Leovac is a method of unlocking additional program parts from a collection of program parts 
already held on the user's client computer. In sharp contrast, claim 1 of the present invention 
is for a method of downloading (not unlocking) the additional program parts to the user's 
client computer. This is made clear in step (h) of claim 1. 

In claim 1, the set of program parts required to create the full functionality object 
cannot be unlocked by a key because the limited functionality object does not include these 
additional program parts. In claim 1, these additional program parts are downloaded and 
added to, not unlocked from within, the limited functionality object. 

The difficulties posed by the prior art is that putting the additional program parts in 
the hands of users before they request and pay for those additional parts, as required by 
Leovac: (1) exposes the software provider to the very real risk that the unlocking process will 
be "hacked"; and (2) results in unnecessary bandwidth and storage consumption in the likely 
event that the user does not request every additional program part. Both of these problems, 
which Leovac leaves unanswered, are resolved in the invention of claim 1 by downloading to 
the client computer additional program parts only as the users request (and pay if that is 
required) for those additional parts. 

Halpem also leaves unanswered the first of these problems. In Halpem, an 
installation package is developed and sent to the user's computer from the server computer. 
The installation package includes only those software components and data that are required 
by the user. Unlike claim 1, Halpem does not contemplate that the user's wants may change 



subsequent to the initial delivery of the software components. As a result, Halpem does not 
consider how additional program parts might be securely released to the user. Halpem is 
therefore of no real relevance to claim 1 . Halpem does not consider how to guard against the 
unlocking process being "hacked" because there are no additional parts in Halpem to be 
unlocked. 

Moreover, there is no express or implied reference in Halpem to step (c) of claim 1 of 
the present invention. In addition to the user-driven customization, claim 1 in step (c) refers 
to a customization according to a rule-set to which the user has no input. This is described in 

the specification of the present invention on page 17, line 10: 

In addition to the user, the server software 4 can also 
customize an object. Object templates can contain a rule -set 
listing the c'ustomizations the server software 4 may make 
before sending the object to the AES client 18. 

No such server-driven customization may be found in Halpem. The text quoted from 
Halpem in the Office Action in support of the disclosure by Halpem of step(c) of claim 1 of 

the present invention begins: 

...in response to the user's selections , the options manager 104 
delivers an installation and/or options specification to an 
installer set generator, [emphasis added] 

This is clearly not a server-driven customization process, as is required by step (c) of 
claim 1. 

Accordingly, and with respect, neither Leovac, or Halpem, when read alone or in 
combination, teach or suggest the invention of claim 1. 
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Claim 9 

3. The Office Action states that Claim 9 is rejected as being unpatentable over U.S. 
Patent No. 6,389,541 to Patterson ("Patterson"), in view of U.S. Patent No. 6,029,182 to 
Nehab et al. ("Nehab"). 

Patterson, in view of Nehab, discloses a method by which users download digital 
content, such as text, video and music, to their client computers. The digital content is 
inaccessible until the user is authorized, normally after payment, to use the digital content. At 
this point, the digital content is unlocked by a token sent to the client computer from a server 
computer. 

The Office Action states at page 8 that step (d) of claim 9, in which the object is 
integrated into the host application, is disclosed in col, 9, lines 26-28 of Patterson. With 
respect, this is incorrect. Col. 9, lines 26-28 of Patterson teaches the storage of a "solicitation 
form 100 ... as part of the object". 

The solicitation form 100 of Patterson is not an "objecf within the scope of claim 9. 
As set out on page 32, line 7 of the present invention's specification, "object" is defined as 
including: 

a combination of computer data and/or logic that encapsulates 
or simulates the realization and/or functionality of a real or 
imaginary object. 

Patterson's solicitation form 100 does not simulate a real or imaginary object. It is a 
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form. It does not pretend or purport to be something other than a form. 

Nehab discloses a system for customizing newspapers according to a "personal-news- 
profile" (column 3, lines 21-24). There is no suggestion in Nehab that the customized 
newspapers will be unique as the object is in claim 9. A newspaper customized for one 
reader might be different from the newspaper customized for another reader, but it does not 
follow that no customized newspaper wilfbe the same as another customized newspaper. 
Two readers might have the same "personal-news-profile", for example. In this instance, the 
newspaper customized to each of their same needs would presumably be the same. 

Claims 13-16 and 24 

4. Claims 13-16, and 24, are rejected under 35 USC § 103(a) as being unpatentable over 
Leovac, in view of Halpem, and further in view of U.S. Patent No. 5,907,617 to Ronning 
("Ronning"). 

The Examiner states at page 10 that the only additional limitation added by claim 13 
to claim 1 is that the user cannot control the limited functionality object but can control the 
full functionality object, as disclosed in steps (d) and (h) of claim 13. 

In respect of the other steps of claim 13 (which the Examiner states to be disclosed in 
claim 1), the conunents made above regarding the Examiner's reasoning in respect of claim 1 
are repeated here. 

In respect of the Hmitation said by the Examiner to be added by claim 13, the 
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Examiner relies on what is said to be a well-known feature of software upgrading systems. 
This feature, according to the Examiner, enables the distribution of "trial" software versions 
with portions that cannot be controlled by a user, and the subsequent upgrading of that trial 
version to a fully functional version. See page 1 1 of the Office Action. 

With respect, this feature is different to the additional feature disclosed by steps (d) 
and (h) of claim 13. In the example given by the Examiner, the users may control those 
portions of the trial software that are made available to them. The Examiner concedes this. 
By referring to "software with portions that cannot be controlled by a user", the Examiner 
distinguishes those portions of the software that cannot be controlled fi-om those portions that 
can be. This is in contrast to the limited fimctionality object disclosed in step (d), which 
cannot be controlled by the user. 

In rejecting claim 13, the Examiner relies in the alternative on Ronning. Ronning, 
states the Examiner, discloses a system by which trial software may be upgraded to fiilly 
fiinctional software. However, like Leovac, Ronning is directed to a system in which the trial 
software is upgraded to fiiUy fiinctional software by '''unlocking the particular software 
program" [emphasis added]. See, for example, claim 13 of Ronning. By comparison, in the 
invention of claim 13, the limited fimctionality object is upgraded to a fiiU fimctionality 
object by downloading the required additional computer code, not merely a key. In Ronning, 
like in Leovac, the complete program code base exists on the client computer prior to the 
upgrade, and a key is downloaded to release it. In the present invention, the additional 
program code that represents the difference between the limited and fiiU fimctionality object 
is only placed onto the client computer upon upgrade. 



These remarks equally apply to the Examiner's rejection of claims 14, 15 and 16 
(which depend on claim 13), and to claim 24 (which the Examiner rejected on the same basis 
as claim 13). 

Further in respect of claim 16, the Examiner states that Halpem discloses at col. 5, 
lines 49-55 the customization of a program uniquely according to the user's preferences. 
With respect, neither in this passage of Halpem, nor elsewhere in Halpem, is this disclosed. 
In the passage at col. 5, lines 49-55, Halpem uses the word "customized", not "unique". This 
is sensible, because, in Halpem, there is no reason to suppose that a user's preferences will be 
unique to that user. Users share common computer platforms and business needs, and there is 
no basis in Halpem to conclude that the resultant program file set will be unique and not be 
created more than once. "Customized" is not a synonym for "unique". Admittedly, the word 
"unique" is used in Halpem' s abstract and summary, but it is used loosely. In the detailed 
description of the invention, and in the claims, where more precision is called for, Halpem 
has no reference to "unique". 

Claim 26 

5. Claim 26 is rejected under 35 U.S.C. § 103(a) as being unpatentable over U.S. Patent 
No. 6,134,593 to Alexander et al. ("Alexander"), in view of Halpem. 

Like Leovac, and like Ronning, Alexander teaches a system of unlocking additional 
software modules upon receipt of a token. In Alexander, as in Ronning, the token used to 
unlock the software is a password (in Leovac, the token is a described as a key). By way of 
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example, module 210^ of Alexander may be a demonstration module with limited 
functionality that is accessible to the user upon installation, but module 2106 may be a full 
functionality module that is only available after payment of a fee, receipt of a password and 
the unlocking of that module. 

In contrast, in claim 26 of the present invention, the additional functionality provided 
by the full functionality program object is not secured with a token, key or password. Rather, 
it is secured against misuse by withholding from the client computer the functional 
components relating to that additional functionality until requested, and if required, paid for. 
Another important difference between Alexander and the present invention is that 
Alexander's full conmiercial module 2106 substitutes for, rather than adds to and integrates . 
with, Alexander's demonstration module 210a. In comparison, the invention of claim 26 
teaches that when the user requests a full functionality object, the functional components 
relating to the additional functionality offered by the full functionality program object is 
downloaded from the server computer. These additional functional components are added to 
and integrated with the existing limited functionality program object, thereby creating the full 
functionality program object requested by the user. 
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Conclusion 



In view of the above, reconsideration and withdrawal of the rejection of the claims 
under 35 U.S.C. § 102 and 35 U.S.C. § 103 is respectfully requested. 

The Office is hereby authorized to charge any fees determined to be necessary imder 
37 C.F.R. § 1.16 or § 1.17 or credit any overpayment to Kenyon & Kenyon Deposit Account 
No. 11-0600. 

The Examiner is invited to contact the imdersigned at (202) 220-4255 to discuss any 
matter concerning this application. 



KENYON & KENYON 
1500 K Street, N.W. 
Suite 700 

Washington, D.C. 20005 
Tel: (202)220-4200 
Fax: (202) 220-4201 
DCl -496523 



Respectfully submitted. 



Dated: June 23, 2004 




Shawn W. O'Dowd 
(Reg. No. 34,687) 
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